Skip to content

[WIP] Enhance MTLN performance#401

Draft
lmdiazangulo wants to merge 17 commits into
devfrom
400-mtln-cpu-performance-improvements
Draft

[WIP] Enhance MTLN performance#401
lmdiazangulo wants to merge 17 commits into
devfrom
400-mtln-cpu-performance-improvements

Conversation

@lmdiazangulo

@lmdiazangulo lmdiazangulo commented May 4, 2026

Copy link
Copy Markdown
Contributor

Profiling seems to show that the problem is with ngspice. A possible solution would be to keep calls to it at minimum. Just when the input contains "circuits" which require it.

@lmdiazangulo lmdiazangulo changed the title [WIP] Enhance MTLN performance by optimizing bundle processing and reducing… [WIP] Enhance MTLN performance May 12, 2026
- Add termination_handler.F90: Fortran-based solvers for simple RLC terminations
  (types 1-10: SHORT, OPEN, SERIES, PARALLEL, and complex RLC combinations)
- Add benchmark.F90: Timing utilities for performance measurement
- Modify network.F90: Add termination type and component values to nw_node_t
- Modify network_manager.F90: Implement hybrid approach using Fortran for simple
  terminations and ngspice only for complex ones (CIRCUIT, NETWORK)
- Modify preprocess.F90: Populate termination info when creating network nodes
- All 31 MTLN tests pass with the new implementation
@Alberto-o Alberto-o self-assigned this Jun 10, 2026
@Alberto-o Alberto-o linked an issue Jun 10, 2026 that may be closed by this pull request
@Alberto-o

Copy link
Copy Markdown
Collaborator

@copilot ubuntu intel compiler and windows intel compiler fail during build due to a problem with the fortran intrinsic routine symlnk. The ubuntu gcc compiler gives no problema with this routine. Explain why and propose a solution

Copilot AI commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

@copilot ubuntu intel compiler and windows intel compiler fail during build due to a problem with the fortran intrinsic routine symlnk. The ubuntu gcc compiler gives no problema with this routine. Exp...

Why SYMLNK fails on Intel compilers:

SYMLNK is a GFortran-specific non-standard extension — it is not part of the Fortran standard and Intel Fortran does not provide it:

  • Ubuntu / Intel (ifx): ifx compiles the call without error (it treats SYMLNK as an external procedure), but the linker then fails because there is no symlnk_ symbol in Intel's runtime library → undefined reference to 'symlnk_'.
  • Windows / Intel (ifx): Intel Fortran on Windows recognises SYMLNK as a keyword with a different (Windows-specific) signature, so when it sees LOWERCASE_STRING(...) as a call argument it conflicts with its own internal declaration → compile-time errors #6406 Conflicting attributes and #6362 The data types of the argument(s) are invalid.
  • Ubuntu / GFortran: GFortran documents and implements SYMLNK as a built-in extension, so it works fine there.

Fix applied (commit a6db0b7):

Replaced all 7 call symlnk(...) calls with a portable private helper create_symlink that uses ISO C binding to call the POSIX symlink() C function directly:

subroutine create_symlink(src, dst)
    use iso_c_binding, only: c_int, c_char, c_null_char
    character(len=*), intent(in) :: src, dst
#ifndef _WIN32
    interface
        function c_symlink(target, linkpath) bind(C, name="symlink") result(res)
            use iso_c_binding, only: c_int, c_char
            character(kind=c_char), intent(in) :: target(*), linkpath(*)
            integer(c_int) :: res
        end function c_symlink
    end interface
    integer(c_int) :: res
    res = c_symlink(trim(src)//c_null_char, trim(dst)//c_null_char)
    if (res /= 0) then
        call WarnErrReport('create_symlink: failed to create symlink from ' // &
                           trim(src) // ' to ' // trim(dst))
    end if
#endif
end subroutine create_symlink

This approach:

  • Works with GFortran, Intel ifx/ifort, and any other Fortran 2003-compliant compiler — ISO C binding is standard
  • No shell involved → no command-injection risk
  • Checks the C return value and reports failures via WarnErrReport
  • On Windows (_WIN32) the entire body is compiled out — the filesystem is case-insensitive so the symlink is unnecessary there anyway

Copilot AI requested a review from Alberto-o June 18, 2026 13:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MTLN is ~2x slower than holland

3 participants